Computer instructions are written in source code. Although a skilled programmer can understand source code to determine what the code is designed to accomplish, with highly complex software systems, a graphical representation or model of the source code is helpful to organize and visualize the structure and components of the system. Using models, the complex systems are easily identified, and the structural and behavioral patterns can be visualized and documented.
The well-known Unified Modeling Language (UML) is a general-purpose notational language for visualizing, specifying, constructing, and documenting complex software systems. UML is used to model systems ranging from business information systems to Web-based distributed systems, to real-time embedded systems. UML formalizes the notion that real-world objects are best modeled as self-contained entities that contain both data and functionality. UML is more clearly described in the following references, which are incorporated herein by reference: (1) Martin Fowler, UML Distilled Second Edition: Applying the Standard Object Modeling Language, Addison-Wesley (1999); (2) Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide, Addison-Wesley (1998); (3) Peter Coad, Jeff DeLuca, and Eric Lefebvre, Java Modeling in Color with UML: Enterprise Components and Process, Prentice Hall (1999); and (4) Peter Coad, Mark Mayfield, and Jonathan Kern, Java Design: Building Better Apps & Applets (2nd Ed.), Prentice Hall (1998).
As shown in FIG. 1, conventional software development tools 100 allow a programmer to view UML 102 while viewing source code 104. The source code 104 is stored in a file, and a reverse engineering module 106 converts the source code 104 into a representation of the software project in a database or repository 108. The software project comprises source code 104 in at least one file which, when compiled, forms a sequence of instructions to be run by the data processing system. The repository 108 generates the UMIL 102. If any changes are made to the UML 102, they are automatically reflected in the repository 108, and a code generator 110 converts the representation in the repository 108 into source code 104. Such software development tools 100, however, do not synchronize the displays of the UML 102 and the source code 104. Rather, the repository 108 stores the representation of the software project while the file stores the source code 104. A modification in the UML 102 does not appear in the source code 104 unless the code generator 110 re-generates the source code 104 from the data in the repository 108. When this occurs, the portion of the source code 104 that is not protected from being overwritten is rewritten. Similarly, any modifications made to the source code 104 do not appear in the UML 102 unless the reverse engineering module 106 updates the repository 108. As a result, redundant information is stored in the repository 108 and the source code 104. In addition, rather than making incremental changes to the source code 104, conventional software development tools 100 rewrite the overall source code 104 when modifications are made to the UML 102, resulting in wasted processing time. This type of manual, large-grained synchronization requires either human intervention, or a “batch” style process to try to keep the two views (the UML 102 and the source code 104) in sync. Unfortunately, this approach, adopted by many tools, leads to many undesirable side effects; such as desired changes to the source code being overwritten by the tool. A further disadvantage with conventional software development tools 100 is that they are designed to only work in a single programming language. Thus, a tool 100 that is designed for Java™ programs cannot be utilized to develop a program in C++. There is a need in the art for a tool that avoids the limitations of these conventional software development tools.
Additionally, conventional software development tools have further limitations that increase the time and cost for developing and deploying software to support distributed computing. Distributed computing allows a business system to be more accessible to enterprise affiliates such as suppliers, customers, business partners, or financial lending institutions. A distributed computing component, such as an Enterprise JavaBean™ (EJB), defines the architecture for developing distributed business objects so that a remote client application run by an enterprise affiliate can access business logic managed by an enterprise application server. Business logic represents the specific details and information flow of a particular industry, such as a reservation system for an airline, a just-in-time parts inventory system for a car manufacturer, or an online stock trading system for a financial services vendor. In general, a conventional three-tier distributed business object architecture typically has a presentation first tier, a business object middle tier, and a relational database third tier. The presentation first tier resides on a remote client application and may include a graphical user interface defined to communicate with an EJB. The EJB (or business object) resides on and is managed by the enterprise application server on the second tier. The business data resides in the database (the third tier).
An EJB, which is typically written in an object-oriented programming language, has a generic set of attributes and methods through which the EJB can communicate the functionality it supports to the enterprise application server after the EJB is deployed. Thus, an EJD enables completely dynamic deployment and loading of an EJB object. The attributes of an EJB allow the runtime behavior of the EJB to be modified when the EJB is deployed to an enterprise application server, without having to change the programming code in the EJB. For example, an administrator of the enterprise application server is able to change the behavior of an EJB by modifying a particular attribute, such as a security behavior attribute, to have another value.
To create and deploy an EJB, a programmer follows the conventional development process for an EJB that includes:
(1) using a graphical modeling tool, such as a computer-aided software engineering (CASE) tool, to model an EJB to be generated;
(2) using the CASE tool to generate a source code framework for the EJB, such as constructs for an EJB class;
(3) using a text editor to develop the code for the EJB, such as attributes and business methods that define the behavior of the EJB;
(4) using an integrated development environment tool or software design kit, such as JDK™, to compile the EJB code;
(5) using a debugger tool suitable for evaluating errors in the EJB code;
(6) using a text editor or comparable tool to write a deployment descriptor, usually in XML, that describes the serialization and other properties of the EJB in the context of a client application;
(7) using a tool provided by an application server vendor to generate a collection or container class. A container object or class instance logically, rather than physically, encapsulates, tracks, and manages zero or more EJBs that have been deployed to the application server. For each EJB that is deployed to or added to a container, the container creates a site that it uses to manage the component;
(8) using a deployment packaging tool to package the deployment descriptor, and the compiled code for the EJB into a deployment package, such as a specific directory or file on the application server;
(9) using another tool provided by the application server vendor to read the deployment package and properly deploy the EJB on the application server; and
(10) repeating the process when runtime errors are discovered with the EJB.
Thus, the conventional development process presents several problems for a programmer. First, to develop and deploy an EJB, the programmer typically performs many of the steps manually, such as writing the deployment descriptor and porting the EJB between tools. Furthermore, the conventional development process dictates that the programmer learn to use an array of different tools which contributes to a longer learning curve for each programmer that slows down the EJB development process. In addition, the array of different tools increases the costs to produce the EJB. Conventional software development tools do not address these problems.
In addition, when runtime errors are discovered with the EJB, the programmer makes manual corrections to the EJB code and deployment descriptor file while repeating the entire conventional development process. Thus, by following the conventional deployment process, a programmer spends additional time debugging, correcting code, and re-deploying an EJB to produce an EJB that runs as desired or error free. Conventional software development tools lack the capability to address these problems. Thus, there is a need in the art for a tool that avoids the foregoing limitations of conventional software development tools.